In Microsoft Vista and later Microsoft operating systems (e.g. Microsoft Windows Server 2008), numerous aspects of the event logging mechanism have been changed in comparison to prior versions of Microsoft operating systems. Some of these changes introduce problems and difficulties for the network administrator who must manage event logs on computers running Microsoft Vista alongside computers running earlier versions of Microsoft operating systems (e.g. Microsoft NT 4.0, Microsoft Windows 2000, Microsoft Windows 2003). Some of these problems include, but are not limited to:
1.) The inability of saved event log files generated from Microsoft Windows NT, Microsoft Windows 2000, Microsoft Windows XP, and Microsoft Windows 2003 (henceforth referred to as EVT files) to be read using traditional function calls when said function calls are executed on computers running Microsoft Vista.
2.) The inability of Microsoft Vista's new event logging functions to properly retrieve and format key event log record fields (e.g. the Category field and/or Description field) from pre-Vista EVT files in a reliable and consistent fashion.
3.) The fact that key user account data traditionally present in the User field of pre-Vista EVT security log files is not included in the security event log files (henceforth referred to as EVTX files) of Microsoft Windows Vista and later operating systems.
4.) The fact that the traditional event log record types of “Success Audit” and “Failure Audit” are missing in Microsoft Vista EVTX security log files with both types of events being consolidated under a generic “Information” event level.
5) The fact that additional event log record fields, such as the Keyword field and the Opcode field have been added to Microsoft Vista EVTX event log files, so that there is now a difference between the number of fields in EVT event log files and EVTX event log files.
6.) The fact that traditional, well-known event identifier codes present in pre-Microsoft Vista security EVT log files have been transposed and/or eliminated in Microsoft Vista security EVTX files.
Even as network administrators migrate their computers to the newer Microsoft Vista and later operating systems which feature the newer style EVTX format event logs they may need to retain the older style EVT format event logs from older systems, especially if they must do so in order to satisfy various security or compliance regulations according to law. Therefore, it is vital to have a mechanism for reliably reading and, when necessary, transforming the log records contained in these older EVT event log files, even if the computer performing reading and transformation is running on Microsoft Vista or a later operating system.
Similarly, for the purposes of effective event log management, it is crucial that administrators have a mechanism for transforming the new fields and data contained in EVTX format event log records into the field structure of older EVT format event log records. For instance, an administrator may elect to collect log record data from both EVT and EVTX format event logs on her network into a central database, and being able to use a common field structure for both log formats would allow for centralized reporting and analysis during routine review.
It would be desirable to the network administrator to have an event log record rendering and transformation engine that would execute on a Microsoft Vista or later operating system and that could overcome the limitations described above, yet still be able to manage the event logs generated from earlier Microsoft operating systems, and reconstitute the data from both logs into a set of fields common to log files from both operating systems. For those skilled in the art, an event log record rendering and transformation engine can be designed to adapt around the problems mentioned above and reconstitute log records into a common set of fields, regardless of the original event log record format (e.g. EVT or EVTX). Such an engine could then be loaded into the memory of the modules of an event log management apparatus, such as the one mentioned in U.S. Pat. No. 7,155,514, which is incorporated herein by reference, for maximum interoperability when managing event logs generated from different Microsoft operating systems.